This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

Size Change: +413 B (+0.02%)

Total Size: 1.81 MB

_{compressed-size-action}

Flaky tests detected in bc66ed4.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9867942148
📝 Reported issues:

• [Flaky Test] Should insert content using the global inserter #57525 in /test/e2e/specs/widgets/editing-widgets.spec.js

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: carolinan <poena@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: beafialho <beafialho@git.wordpress.org>
Co-authored-by: henriqueiamarino <iamarinoh@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Hey @carolinan 👋

Would it be possible to have this be a pattern that consists of a row block with the tag name set to nav instead?

I'm not sure a custom block is the right answer for the valid issue you point out :)

The reason for that is in the linked issue.
The patterns are not surfaced the same way as blocks and are more difficult to find. And having the block would make it consistent with the query pagination.

I would still prefer for this to be a block, but how does one even add a new core pattern? Are they added by issues and PR's to the pattern directory repository?

I would still prefer for this to be a block, but how does one even add a new core pattern?

There are a mixture of ways at the moment. There are some in the block-patterns folder in core:
https://github.com/WordPress/wordpress-develop/tree/trunk/src/wp-includes/block-patterns

They're registered here:
https://github.com/WordPress/wordpress-develop/blob/e3e7fdbf7c3fd9f04871118a16b98f1544e94984/src/wp-includes/block-patterns.php#L18-L37

The majority are registered from the pattern directory, those that are 'featured' or have the 'core' keyword:
https://github.com/WordPress/wordpress-develop/blob/e3e7fdbf7c3fd9f04871118a16b98f1544e94984/src/wp-includes/block-patterns.php#L211-L287

These patterns are only loaded when core-block-patterns support is active.

I'm not sure what the preference is for adding new bundled patterns. This one seems more like a useful utility pattern rather than the more stylistic patterns in the directory, so maybe the first way?

edit: also just to mentioned that if you wanted to experiment with adding the pattern in the gutenberg plugin to start with, it should be possible to add code similar to how those core patterns are loaded in a lib/compat/wordpress-6.7 folder

I still disagree that this should be a pattern and not a block. It is an accessibility issue that the individual blocks are added without the nav element.

It would be good to document how to add a new pattern.

I still disagree that this should be a pattern and not a block. It is an accessibility issue that the individual blocks are added without the nav element.

Sounds like a good argument for it being a block. Group doesn't support nav, and I don't think there are options for making blocks visually hidden (for the heading), so it'd be hard to make a pattern work.

If you go with the blocks approach, could it be worth also making the post-navigation-link blocks only insertable as a child of this new block (using the parent block property)? That way it'd also help to reduce the number of blocks available globally and enforce the accessibility concerns.

It is possible to only have one of the links, and then the nav may not be the correct element to use.

Edit: Actually there are of course situations where this will only show one link: when there are no previous or no next posts, so ignore the comment above.

But should we remove the ability to only insert one of them?

Edit: Actually there are of course situations where this will only show one link: when there are no previous or no next posts, so ignore the comment above.

But should we remove the ability to only insert one of them?

Are you saying that when there's only one link, there shouldn't be a wrapping nav element?

If so, would being able to insert those blocks alone solve that issue? I think the templated blocks for pagination will be the same, whether at the the start, middle, or end of pagination. The blocks themselves would require some conditional logic on what to display.

No, I am saying ignore the comment about not using nav when it only contains one link :)

No, I am saying ignore the comment about not using nav when it only contains one link :)

So is having a nav for a single item is acceptable a11y wise? I couldn't see something specific in the docs. If yes, should we just wrap the individual blocks with nav?

It might be valid HTML, but no, because both links are part of the same navigation.
It should work the same as the query pagination.

I made the following changes:

• Added post navigation as the parent for post navigation link.
• Removed the template lock from post navigation so that the inner blocks can be deleted.

The behavior of the post navigation block when all inner blocks are deleted matches the button and columns block:

• The parent is empty in the editor
• The empty parent block is printed on the front.

It would be good to solve the empty tag on the front for all these blocks.

Question, do I need to create a Trac ticket for the changes to the list of registered blocks in lib/blocks.php?
According to the error, I do, but isn't this list automated?

"// This file was autogenerated by tools/release/sync-stable-blocks.js, do not change manually!

And for @beafialho, the reason I pinged you was because I am wondering wether this change offers enough flexibility for designers to position the next and previous post links.

Thank you for the ping @carolinan! Just tried this and it seems like an improvement that makes sense overall.

When I click the "Post Navigation" block, I am only seeing the typography settings in the styles panel. My suggestion is that this block has the same settings that are available for the row block (where we usually add both "Next" and "Previous" links), as this allows for more granular design customization. Here's a screen recording of that I mean:

I also suggest that we make it possible to add the "Next" and "Previous"links if one desires to, outside of the Post Navigation block. Is this helpful?

cc: for your input as well @richtabor @henriqueiamarino

I am with @beafialho here. Having the same settings from the row block will certainly enhance customization and add consistency. In the future, this should be extended to all navigation elements and pagination, which is similar. For instance, why not add these options to the Post Navigation?
This is not necessary at the moment, but I firmly believe it's a path to take.

I am with @beafialho here. Having the same settings from the row block will certainly enhance customization and add consistency. In the future, this should be extended to all navigation elements and pagination, which is similar. For instance, why not add these options to the Post Navigation? This is not necessary at the moment, but I firmly believe it's a path to take.

The icon option is already on the individual inner blocks.

Yes this feedback is helpful, thank you.

• I have removed the parent limitation from the post navigation link.
• I have added border, padding, top and bottom margin, and block spacing.

I am unsure about min height and shadow?

It does feel strange that the inner post navigation link blocks do not have padding and margin settings.

I'm not really fond of the idea of a new block and maybe the strongest argument would be discoverability of a pattern that would do that. A thing that resonated with me is that is indeed quite similar to Query Pagination, so it could justify the wrapper block(if we eliminate the pattern approach).

Having said that, if we go with this approach, should we consider moving some controls like the arrow on the new block like we do for the Query Pagination, to update both inner blocks together?

I would need some help with how to move the icon options:

• Designers has asked to continue to be able to place the individual next and previous blocks, so does that mean the option would not be moved, but be on both the inner blocks and the parent wrapper? Then it would be inconsistent again.
• What happens / what should happen with existing, already placed blocks that use the option`?

Designers has asked to continue to be able to place the individual next and previous blocks, so does that mean the option would not be moved, but be on both the inner blocks and the parent wrapper? Then it would be inconsistent again.

Yeah, in that case it doesn't make sense to move controls to the parent.